4. Connection Filtering
Connection
filtering inspects the IP address of the remote server that is trying
to send the message to determine what action to take on an inbound
message. If a specific server is found on the IP Allow list or on the
list of an IP Allow list provider, the message is not scanned anymore but directly marked as not spam. Similar to the IP Allow list, an IP
Block list also exists that consists of servers that are not allowed to
send messages because they have been identified as spam senders. The
following sections discuss IP Allow lists and IP Block lists as well as
list providers.
Note: It
might seem obvious, but if your Exchange organization receives all
messages from a smart host server, the sender's IP address will always
be the same. To enable Connection
Filtering to work correctly, you need to add this smart host server's
IP address, along with the IP addresses of all SMTP servers capable of
routing e-mail, to the InternalSmtpServers list via the Set-TransportConfig
cmdlet. If the Hub server where you enable anti-spam is the only SMTP
server in your organization, you must add its own IP address to the list.
4.1. IP Allow List
An IP Allow list is a static list
of trusted IP addresses manually created and managed by the Exchange
server administrator. IP Allow list inspection is the first in the
execution chain of Connection
Filtering. You can include trusted IP addresses in the IP Allow list,
such as the IP addresses of SMTP servers at your partner organizations.
If a connection request comes from an IP address on the IP Allow list,
the server does not apply additional anti-spam filtering and accepts the message.
To configure an IP Allow list and either add a single IP address or an IP range to the list, you need to use the Add-IPAllowListEntry cmdlet.
4.2. IP Allow List Providers
IP Allow List Providers is a feature that allows you to take advantage of dynamic safe lists of IP addresses
maintained by a third-party providers. To use these lists you need to
configure an external provider that maintains a safe list of SMTP
servers instead of defining it yourself. In essence, configuring IP
Allow List Providers is very similar to configuring IP
Block List Providers and both use the same technology to retrieve the
verdict about the connecting IP address from the providers.
Note: Most
of the messaging administrators I know do not consider IP Allow List
Providers for deployment and infrequently use IP Allow lists. This is
due to the fact that all messages submitted from the addresses on IP
Allow lists are immediately extracted from the anti-spam scanning and
if a spam attack comes through one of the addresses on an IP Allow
list, it won't be detected by the consecutive anti-spam layers and spam
will penetrate the Exchange organization. Although the adoption of the
IP Allow List Providers feature is not very significant, a carefully
implemented static IP Allow list allows you to receive e-mail from
trusted parties fast, without the loss of content, increasing end
users' satisfaction.
4.3. IP Block List
Similar to the IP Allow
list, the IP Block list feature examines connecting IP addresses
against the static local list of IPs manually maintained by the
Exchange administrator. In many cases administrators include on the
list IP addresses of SMTP servers known to send spam or other MTAs from
which they do not want to receive e-mail. If the Connection Filtering
agent finds the IP address of the sending server on the local IP Block
list, the server rejects the message without allowing the connecting
party to initiate SMTP mail transaction.
You can configure a single IP
address or IP address ranges that are blocked, and you can also define
an expiration time on each entry so that you can block an IP address
temporarily.
If you enable Sender Reputation filtering, it will add the IP addresses that exceed defined Sender Reputation Level (SRL) to the IP Block list for the configured amount of time.
4.4. IP Block List Providers
IP Block List Providers, or real-time
block lists (RBLs), contain a list of known IP addresses of SMTP
servers that are considered risky for sending spam. Because spammers
use a variety of techniques to send spam and fool the receiving servers
into accepting it, identifying their IP addresses and verifying them
for "spamminess" is a very useful way to prevent spam from entering
Exchange organizations.
If enabled, the Agent will send a
DNS query to a manually configured IP Block List Provider and if the
response from the provider indicates that the connecting IP is on the
list, the Connection Filtering agent will reject mail transaction after the RCPT TO: command.
The rejection logic has been
designed to accommodate various exceptions or cases when one or more
recipients in the Exchange organization might need to receive all
e-mail sent from the block-listed IP because of various business needs. (For example, spam
analysts might need to investigate a newly unfolding spam attack or the
Exchange administrator might set up a honey pot account to collect mail
for forensics.) Whatever the reason, you can configure specific e-mail addresses as exceptions so that they will receive all messages, even if the connecting IP is on the RBL.
There are multiple real-time IP
Block List Providers who maintain and service RBLs. You need to account
for many factors when deciding which RBL provider to use. Some of the
most important factors are the ability of the provider to service
requests for removal of mistakenly or maliciously block-listed IP
addresses, supportability channels, and responsiveness to customer
issues. Of course, you also need to account for the cost of using the
provider's services. Most RBL providers do not charge fees if the
number of DNS queries is relatively low—for example it does not exceed
250,000 queries per day. However, if the number of queries exceeds this
threshold, the provider won't service requests originating from
high-volume IP addresses and instead will ask you to obtain their list
via a zone file transfer, and the provider will charge a fee for that.
Many RBL providers are available on the market, including the following:
cbl.abuseat.org
dnsbl.sorbs.net
spamhaus.org
bl.spamcop.net
Note: The
list of common IP Block List Providers should be handled with care
because the results change over time. Please watch your Agent Log
carefully to prevent the blocking of messages without a reason. You
should consider writing a PowerShell script that is automatically
executed every day to look for problems in the Agent Log as the size of
the log might increase very quickly.
A very useful cmdlet to determine whether your IP Block List Providers are working correctly is the Test-IPBlockListProvider cmdlet. You can either test a single RBL or you can test an IP address using all your configured RBLs, as shown in Figure 3.
Please be aware that the
more RBLs you configure, the longer the verification process will take.
Thus it is recommended not to exceed two or three RBLs. One positive
match is sufficient to block the sender.
Another advantage of
using Forefront Protection 2010 for Exchange Server is that it relieves
administrators of the work required to configure, maintain, and
administer IP block lists. The product comes with a feature called Forefront DNSBL, which is an aggregation of multiple
feeds from many RBL providers, including SpamHaus and internal
Microsoft feeds such as the block list from the Forefront Online
Protection for Exchange team. The aggregated feeds are combined into a
single database and positioned on a Microsoft-owned DNS infrastructure.
The feature is administration- and maintenance-free, meaning the
Exchange administrator has nothing to configure or monitor/maintain.
5. Sender Filtering
The Sender
filter compares the sender on the MAIL FROM: SMTP command to a list of
senders or sender domains that are prohibited from sending messages to
the organization. After the sender is filtered, there are two possible
actions: reject the message or stamp the message and deliver it. The
blocked sender information is included as one of the criteria when
content filtering processes the message.
Note: As
a best practice you should select the Block Messages That Don't Have
Sender Information option in Sender filtering properties. If a message
does not contain a sender address, it is extremely likely to be spam
anyway.
6. Recipient Filtering
The Recipient filter compares the message recipients on the RCPT TO: SMTP command to an administrator-defined Recipient
Block list. If a match is found, the message is not accepted for the
recipient specified on the Recipient Block list but will be delivered
to other recipients who are not on the list. If multiple recipients are
listed on the message and some are not on the Recipient Block list,
further processing is done on the message. The Recipient
filter also compares recipients on inbound messages to the local
recipient directory to determine whether the message is addressed to
valid recipients. When a message is not addressed to valid recipients,
such a message can be safely rejected during SMTP transaction.
Note: As a best practice you should select the Block Messages Sent To Recipients That Don't Exist In The Directory option in Recipient
filtering properties. This will automatically reject any message
destined for e-mail addresses that do not exist in Active Directory.
This will be verified to all authoritative, configured Accepted
Domains. For internal relay domains this option will not be considered.
Enabling the Block Messages Sent To Recipients That Don't Exist In The Directory option might disclose your Active Directory recipient information to malicious users executing a Directory
Harvesting Attack (DHA) against your organization. To circumvent such
attacks Exchange server enables you to configure tarpit intervals (tarpits
are delays between the command coming from a remote computer and when
Exchange server replies confirming or rejecting valid recipients). This
is a highly effective technique that renders DHAs against Exchange
organizations not feasible. The tarpit option is configurable and the
default value is 5 seconds (which means Exchange server will delay
response to every invalid recipient command for 5 seconds).
7. Sender ID Filtering
The Sender ID framework
is an industry standard that allows companies to verify the IP
addresses for incoming messages to ensure that they come from
authorized servers. The Sender ID Framework provides highly effective
protection against e-mail domain spoofing and phishing schemes. However, Sender ID is not used by many large corporations.
To take an advantage of
the Sender ID Framework, domain owners must register all the IP
addresses for all the SMTP servers that send e-mail from their SMTP
domain with special DNS records. When using Sender ID filtering, the
recipient messaging server initiates a DNS lookup to verify that the
connecting IP is allowed to deliver messages on behalf of that domain.
If the domain information does not contain the connecting server's IP
address, the messages can be filtered out. Figure 4 illustrates the Sender ID filtering process.
As displayed in the figure, Sender ID filtering follows these steps:
The message is received by the Exchange Edge Transport server.
The
Edge Transport server checks the IP address of the sending SMTP server
and queries DNS for the Sender ID record. Sender ID records are in fact
Sender Policy Framework (SPF) compatible records and both SPF versions are supported in the Sender ID Framework.
Depending on the result, the following actions are taken:
If
the Sender ID record matches the sending SMTP server, the Edge
Transport server accepts the message into the Exchange organization.
If
the Sender ID record does not match, the Edge Transport server will
respond in the configured way—meaning it either rejects, deletes, or
forwards the message with additional information added to its header
indicating that it failed authentication.
If you're interested in additional information about the Sender Policy Framework (SPF), you can access it at http://www.openspf.org/.
7.1. Sender ID and Sender Policy Framework (SPF) records
To take an advantage of the
Sender ID Framework and protect their own name brand and reputation,
each e-mail sender must create a Sender ID or SPF record and add it to
their domain's DNS records. The record is a single text (TXT) record in
the DNS database that identifies each domain's e-mail servers. Sender
ID records can use several formats, including the SPF record format
examples as listed in Table 1.
Table 1. SPF Record Configuration Examples
DNS CONFIGURATION | DESCRIPTION |
---|
Litware.com. IN TXT "v=spf1 mx -all"
| This record indicates that all servers that have an MX record for the Litware.com domain are allowed to send messages. |
Litware.com IN TXT "v=spf1 ip4:10.10.0.20 -all"
| This record indicates that only the server with the IP address 10.10.0.20 is allowed to send messages for Litware.com. |
Litware.com IN TXT "v=spf1 a -all"
| This record indicates that any host with an A record can send mail. |
Litware.com IN TXT "v=spf1 mx mx:berlin-et01 .emea.litware.com mx:berlin-et02.emea .litware.com -all"
| This record indicates that only the listed servers are allowed to send messages for Litware.com. |
Additionally, you should be aware of the different configuration options you have using the all part of the SPF record in DNS. The options are listed in Table 2.
Table 2. SPF Record all Options
SPF RECORD | DESCRIPTION |
---|
-all | Only
IPs in the text record can legitimately send mail on behalf of the
domain—otherwise the e-mail is a forgery. For example, "v=spf1 mx –all"
means only IPs of MX records can legitimately send on behalf of the
domain; all others are forgeries. You should always consider this SPF
record as the default.
However, "v=spf1 –all" means no IPs are associated with sending domain
and as such this domain is not involved in sending mail at all, so all
mail claimed to be from the domain is a forgery. This option maps to
hardfail status in Sender ID filter and the message will be deleted. |
~all | E-mail is likely a forgery but this is clear. Sender
ID filter, encountering such an option, will provide softfail status
and the e-mail won't get deleted, but instead will get accepted into
the Exchange organization. |
+all | Use
this option with care as it maps to the PASS status in Sender ID
filter. By implementing this syntax you guarantee that your domain
never sends spam. |
?all | It's
ambiguous if the e-mail is a spoof or good. The option is used for
testing Sender ID functionality and maps to Neutral status and e-mail
will be accepted into the Exchange organization. |
Microsoft provides the Sender ID Framework SPF Record Wizard to verify your organization's Sender ID and SPF records in DNS. It is available at http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/. The wizard allows you to create a Sender ID record that meets your organization's exact needs.
7.2. Configuring Sender ID Filtering
Sender ID filtering is
enabled by default with the option to stamp the header with Sender ID
verdict and continue message processing. Other possible options are
Reject and Delete.
It is very important to
understand that the filter will implement Reject or Delete actions if
and only if the Sender ID validation on the connecting IP failed. This
means that the connecting IP cannot legitimately send mail on behalf of
the domain it claims to be from, which is pretty much a spoofing
attempt. In all other cases (for example, in the event of a transient
DNS error, or if Sender ID records are misconfigured, do not exist, or
are temporarily not available) the filter will not reject or delete
message. It will stamp the verdict onto the message and pass it on to
the next filtering technology.
Sender ID is not a mandatory
requirement in Internet SMTP messaging; however, it is the technology
that will help protect your company's name brand and prevent spoofing
attacks. But the evidence is that many large companies don't use Sender
ID yet. For example, at the time of this writing, neither HP nor GE nor
Siemens publish Sender ID records in DNS; whereas IBM, Microsoft, and
Google do.
In many cases Sender ID is your best and only defense when Zero Day attacks unfold, so it is recommended that you create and maintain Sender ID records and implement Sender
ID filtering in Reject mode. Sender ID, when correctly implemented, is
very safe to use and helps to improve your reputation as a responsible,
legitimate sender.
To verify Sender ID, you can use the Test-SenderID cmdlet and enter a domain as well as the Server IP address to see the result.